jnet: a successor to gnet

After several years of hoping that more recent programs would allow his graph tool gnet to be quietly forgotten, the author has finally bowed to requests from many colleagues to resurrect the project. This paper reviews some aspects of the history of stratigraphic software and presents an early prototype of jnet, a successor to gnet written in Java. jnet is intended to offer similar facilities to its predecessor, but with significant improvements in database connectivity, interoperability with other programs, and to enable access from anywhere. Whereas gnet was limited to Windows platforms, jnet may be used on a variety of desktop and mobile systems as well as through a Web interface. Background: a brief history of computerised stratigraphy In what now seems like an earlier age of archaeological computing, the application of computers to the manipulation and analysis of stratigraphic sequences probably began with Wilcock's STRATA program (1975). Although it now seems primitive, STRATA demonstrated that a computer program could be used to derive a logical sequence from a collection of relationships between stratigraphic layers. The appearance of this program also led to the start of a debate about the appropriate use of computer based techniques in stratigraphic sequencing and, more generally, in excavation recording that was to continue for some time. STRATA’s input was a complete set of recorded observations of stratigraphic relationships, and its output was a complete sequence for the site. It was designed as a batch process in which all of the available data was interpreted in a single run to produce a deterministic solution. This ‘black-box’ approach was seen by many as antithetical to the process of developing an understanding of a site and its stratigraphy during excavation (see, for example, Harris 1975). In practice, contemporary hardware and software limitations severely restricted the size of the models that could be handled and processing even very small sites might take several hours. However, it was to be some time before interactive computer methods could offer an alternative approach. A decade later, two papers presented at the 1985 CAA Conference prepared the foundations for several subsequent developments (Haigh 1985; Ryan 1985a). Haigh, brought a mathematician’s view to sequencing by identifying the problem as the ordering of a partially ordered set, or poset. Ryan arrived at a similar position from a computational perspective. He had recently been working on the related problems of drawing genealogical diagrams and graphical representations of computer file stores. He observed that existing system software, the UNIX ‘topological sorting’ program, tsort, was used to solve a similar problem in traversing and ordering the contents of a hierarchical file store. With simple extensions to handle cross-links in a hierarchy—symbolic links in a UNIX filestore, marriages linking lineages in genealogy—the core algorithm of tsort became the basis for gtree, a generalised program for drawing and manipulating tree-like data structures (Ryan 1985b). Whilst some concentrated on the stratigraphic diagram, or ‘Harris Matrix’, as a distinct issue, others began to develop systems to integrate relationships and sequences into more complete excavation recording and analysis tools. Rains, for example, introduced the forerunner of his integrated archaeological database at this time (Rains 1985). Soon after, Alvey presented his Hindsite program which used AutoCAD to maintain single-context plans together with a representation of the relationships between layers (Alvey 1989). Both of these systems represented significant early contributions to the development of excavation recording and visualisation. Again in 1990, the CAA Conference proceedings included several papers on computer processing of stratigraphic data. Boast and Chapman (1991) presented an approach based on SQL queries against a database, Desachy and Djindjian (1991) discussed a simple sorting algorithm, whilst Huggett and Cooper (1991) reviewed the current state of the art and discussed the practical utility of various approaches. In the same volume, Herzog and Scollar (1991) introduced a fully automated system for producing stratigraphic diagrams. Though able to handle more realistic data volumes with reasonable speed, Herzog’s program followed Wilcock’s earlier approach of producing a solution as the output of a batch run. However, improving technology was later to make it realistic to run the program whenever new data became available during excavation. In this way, the sequence diagrams produced by the program could evolve as excavation progressed. The main limitation of this approach was that the excavator could exert little influence over the final form of the diagram. Following Harris and others’ earlier reservations about 'black box' methods, Ryan (1998) had developed an interactive system called gnet. The design thinking behind gnet was quite different to that behind Herzog’s program. Whilst accepting that automated layout and the ability to print stratigraphic diagrams were important capabilities, the ability to interact with and explore the diagram—what we would now call visualisation—were seen as the key to supporting the excavator’s need to develop and maintain an intimate understanding of the structure of the site as excavation progressed. As Herzog and Scollar noted (ibid), however, the program required what was then advanced hardware. Initially, it ran only on UNIX workstations, and even the subsequent PC version required a mouse and a specialised graphics card, items that few archaeologists possessed at that time. Fortunately, time was to make this a less restrictive requirement. gnet was a development of an earlier program, gtree, redesigned to handle networks or lattices as its primary data structure, rather than the trees with added cross-links of its predecessor. It was, in fact, a general-purpose graph browser/editor that could be configured to suit a wide range of applications from stratigraphy and genealogy to software engineering design processes. Much of its development was, however, informed by archaeological requirements as this had rapidly become its most widely used application. Intensive development, in collaboration with excavators in several countries, took place in the first half of the 1990s. Beyond simple error checking and interaction with diagrams, the final system (Ryan 1995) offered a variety of facilities aimed at post-excavation tasks, including methods for grouping contexts to form phase diagrams and other high-level interpretive abstractions. Multiple views could be displayed simultaneously. It was possible to switch rapidly between a complete graph showing all recorded links and those that formed the stratigraphic sequence, or between grouped and expanded views. Where plan data could be provided in a suitable form, a 2.5D view similar to that introduced in Alvey’s Hindsite program could also be displayed. Database connectivity enabled gnet to be closely integrated with excavation recording databases and several techniques were explored to enable linkage with other widely used programs. Together, these features enabled the program to function as a component in a larger toolkit. One of the less desirable outcomes of this phase of development was that, although ealier versions had been built for UNIX, Macintosh and PC platforms, by 1995, gnet could only be run on Windows machines. The later versions were dependent on several Windows-specific C++ class libraries, on ODBC to provide connectivity with databases, and on OLE for linkage with other programs. Eventually, development ceased with the introduction of 32 bit versions of Windows and the accompanying changes in ODBC and OLE. Nevertheless, some users report continuing use of the program on modern operating systems, whilst others have reported failure despite many ingenious attempts to make the program work. The author himself has not been able to run the program on any of his machines for more than five years. Since its demise, there has been a steady stream of requests from colleagues to resurrect the gnet project and to bring the program up to date. Unfortunately, the considerable effort required merely to reproduce the program in a modern form was always difficult to justify when working in a research environment. For several years, the author’s research focus has been in mobile and ubiquitous computing, and the development of collaborative tools for use in mobile and ad hoc networks. Archaeological applications of this work have centred on data collection and access to remote information resources during field survey campaigns (Ryan et al. 1999; van Leusen & Ryan in press) and in tourist guides that can adapt to the level of specialist knowledge of the user (Ryan in press). Others have investigated the use of mobile and handheld devices in excavation recording (for example, Powlesland & May this volume; Ancona et al. 1999) but, so far, there has been little work that seeks to integrate models of the stratigraphic sequence into such mobile tools. During this work on mobile collaborative tools, the need arose for a program to act as a simple test bed for research purposes. This need has now provided the justification to develop a successor to gnet. The remainder of this paper outlines the initial design requirements for this new system, and describes the current state of implementation of a prototype1. Design requirements The fundamental requirement for the new system was to provide equivalent graph visualization and editing functions to those of gnet. However, unlike its predecessor, it was also required to support a wide range of computing platforms and environments. It should work as a stand-alone application on desktop, laptop and handheld devices, and should support collaborative working in a networked environment. Like gnet, it should provide shared access to centralised databases for multiple users. Mobility implies the need to operate in wireless network environments and hence to be able to survive disconnections from the network. Indeed, the program might be used for long periods with no network connection and so would need to ensure synchronisation during relatively brief periods of connectivity. Combining this with the collaboration and shared data requirement leads to a system that can work both on and off-line, and can resolve conflicts between updates made by different users. gnet had offered only limited output capabilities. Diagrams could be printed, if necessary on multiple sheets of paper, but there was no way of exporting or displaying read-only diagrams either as images for publication or as models that might be used by a CAD system. Similarly, the ability to use the diagram as an exploratory interface for querying underlying data was not separable from its editing and other graph manipulation capabilities. Instead of trying to build all of these capabilities into a single monolithic program, it was decided to maximise the use of existing software and technologies. Diagram export, read-only views and a simple query interface could be provided through web browser interfaces. Compatibility with existing mobile infrastructure developed for other applications, together with the requirements to work on multiple platforms led to the choice of Java as the implementation language for this new tool. This in turn inspired the choice of the name, jnet, reflecting both the wholly new implementation and the ancestry of its core functionality. Figure 1: the basic architecture of jnet.